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Constraint : HLR MODG 01 UU in AnActor 



General) Properties | 



Name: 



I HLR MODG 0100 



Stereotype: |SRS 



Defined in: | AnActor 
Body 



Description 



Title: Reset behavior 

Content: The application software shailperform 

a reset of the partition in less than 300 ms 

except in case of MACSII limitation. 

Category: Functional 

Upward Req: MB_BCSJMA_20, 

MB BCS IMA 37,MB SCS IMA 37. 
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(57) Abstract: The invention relates to a 
UML-based requirement traceability method, 
characterized in that when a model is created 
during modelling, a requirement is made 
in relation to said element and the upstream 
requirement, which caused the creation of the 
element, is informed. 

(57) Abrege : La presente invention est rela- 
tive a un procede de tracabilite des exigences a 
partir d'un modele UML, et elle est caracterise 
en ce que lors de la modelisation, lorsque Ton 
cree un element d'un modele, on pose aussitot 
une exigence sur cet element, et on renseigne 
systematiquement l'exigence amont qui a pro- 
voque la creation de cet element. 
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PROCEDE DE TRACABILITE DES EXIGENCES A PARTIR D'UN 

MODELE UML 

La presente invention se rapporte a un procede de tra^abilite des exigences a 
partir d'un moddle UML. 

II existe de nombreuses methodes de tra9abilite des exigences k partir d'un 
module, mais il n'en existe pas pour les modules en langage UML. De plus, ces 
methodes connues sont limitees au seul code, done elles ne sont pas transposables au 
langage UML. 

La presente invention a pour objet un procede de trasabilite des exigences k 
partir d'un modele, qui puisse s'appliquer k la modSlisation UML. 

Le procede conforme k Pinvention est caracterise en ce que lors de la 
modelisation, lorsque Ton cree un element d'un moddle, on pose aussitSt une 
exigence sur cet element, et on renseigne systematiquement P exigence amont qui a 
provoque la creation de cet 616ment 

La presente invention sera mieux comprise a la lecture de la description 
detaillee d'un mode de realisation, pris k titre d' exemple non limitatif et illustre par 
le dessin annexe, sur lequel : 

la figure 1 est une vue d'une interface graphique d'un outil 
« RHAPSODY » montrant une exigence d'un modele UML, telle 
qu'utilisee par la presente invention, 

la figure 2 est une vue de F interface graphique de la figure 1, 
montrant un exemple de rattachement de contrainte, conform&nent 
au procede de Pinvention., 
- la figure 3 est une vue de Pinterface graphique de la figure 1, 
montrant un exemple de rattachement d'exigence UML, 
conformement au procede de Pinvention, et 

la figure 4 est un diagramme montrant un exemple d'enchainement 
d'activites entre les outils « RHAPSODY » et « DOORS », 
conformement au procede de Pinvention. 
On sait que la creation d'une exigence UML suit toujours une activite de 
modelisation, mais il ne faut surtout pas creer les exigences, puis modeliser ce qui est 
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specifie dans ces exigences, car cela conduirait in6vitablement a une mauvaise 
utilisation d'UML et de la notion d'objet. 

II est conseille, a chaque fois que Ton cree une exigence qui rafiBne une ou 
plusieurs exigences anion!, de renseigner systematiquement la balise 
5 « UpwardReq : » avec l'identificateur de ces exigences amont. Ainsi, on gere la 
trasabilite des exigences au moment de leur creation et non a posteriori sur 
r ensemble des exigences. 

Une exigence est representee dans le modele UML (avec Poutil de 
modelisation « RHAPSODY » de la societe I-LOGTX) par une contrainte UML 
10 appelee « Exigence UML » . Un exemple en a ete represents en figure 1 . 

Toutes les Exigences UML doivent Stre definies de la mSme maniere selon le 
modele (« template » en anglais) suivant : 

- le champ « Name » (nom de F Exigence UML) doit contenir l'identificateur 
de l'exigence. Get identificateur doit permettre d'identifier le niveau de 

15 l'exigence. Si F exigence est de haut niveau, l'identificateur doit commencer 

par « HLR_ », et si l'exigence est de bas niveau, l'identificateur doit 
commencer par « LLR_ ». 

- le champ « Stereotype » (stereotype) doit contenir le niveau de specification 
de l'exigence (SSS 5 SRS ... ). En effet, les exigences d&finies pour ces 

20 differents niveaux de specification sont toutes presentes dans le meme 

modele UML. Renseigner ce champ stereotype est done le seul moyen de 
differencier les exigences en fonction de leur niveau de specification et done 
d f identifier vers quel module « DOORS » (l'outil DOORS est un outil de 
gestion d'exigences de la society TELELOGIC) elle doivent §tre redirigees. 

25 - le champ « Description » (description de FExigence UML) doit contenir les 

balises suivantes : 

-« Title : » (titre), suivie du titre de l'exigence, 

-« Content : » (contenu), suivie du texte de l'exigence, « Upward 
Req : » (requete amont), suivie de la liste des identificateurs des 
30 exigences amont k Forigine de cette exigence. Les identificateurs 

doivent etre separes par une virgule (« , »). 
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On remarquera que l'ensemble des attributs de gestion d'exigences, tels que 
definis dans le processus DOORS, ne font pas partie du modele UML. L'activitS qui 
consiste a renseigner ces attributs s'effectue directement sous DOORS, suite k la. 
remontee des exigences UML sous DOORS. 

5 Le rattachement des Exigences se fait de la maniere suivante. Dans l'outil 

Rhapsody, le seul moyen d'associer une Exigence UML) a un Element du modele est 
de la rattacher a cet 616ment en utilisant la fonction « Add New / Constraint », 
comme represents sur l'exemple de la figure 2 (pour Fexigence « Solution »). 

Cette fonction de rattachement est disponible sur tous les elements d'un 
10 moddle (« Package » 3 Classe, Operation, Acteur, Cas d'utilisation, Machine k etats, 
Etat... ). 

Actuellement, la norme XJML I A definit qu'une contrainte (une Exigence 
UML) peut etre rattachee a plusieurs elements UML, or RHAPSODY ne le permet 
pas. Par consequent, lorsque l'on cree une Exigence UML) qui se repercute sur 
15 plusieurs elements du modele, on la rattache a l'element commun contenant 
l'ensemble des elements sur lesquels Pexigence se repercute. 

On decrit ci-dessous de fagon non limitative deux exemples d'un tel 
rattachement: 

si deux classes d'un meme « package » sont concernees par la meme 
20 Exigence UML, alors cette Exigence UML sera rattachee au « package » 

contenant les deux classes, 

si une Exigence UML) se repercute sur trois methodes d'une meme classe, 
alors cette Exigence UML) sera rattachee a la classe. On a represent^ en 
figure 3 un exemple d'un tel rattachement d'Exigence UML (Exigence de 
25 haut niveau « HLR_01 » a deux classes SMyClass » et « MyOtherClass »). 

Selon une autre caract&ristique de Pinvention se rapportant a l'incidence sur 
la persistence des Exigences UML, lorsque l'on supprime un element du modele, 
toutes les Exigences UML rattachiees a cet element (et a tous les elements rattaches a 
cet element) sont supprimees elles aussi. 
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Selon encore une autre caracteristique de l'invention, on exporte les 
Exigences UML sous DOORS, Suite a une Stape de modelisation UML, qui 
correspond en general a un niveau de specification donnS, on obtient un modele 
contenant un ensemble d'SlSments UML et d'Exigences UML, stereotypies avec le 
5 niveau de specification correspondant Quand le modele UML a atteint un Stat stable, 
on peut alors importer le modSle UML sous DOORS afin d'effectuer les activitSs de 
gestion et de tragabilitS d'exigences. 

On a schematiquement represents en figure 4 un exemple d'enchalnement 
d'activitSs d'exportation de RHAPSODY vers DOORS. Sur cette figure, on a 

10 represents eote-a-cote les outils RHAPSODY et DOORS. Pour le premier, on a 
represents Tarborescence d'un modele UML et trois Stapes successives de 
developpement ayant atteint chacune un Stat stable de modSlisation, ces Stapes Stant 
respectivement rSfSrencees Niveau 1 & Niveau 3. Au fur et k mesure du 
dSveloppement, les modSles successifs sont importSs dans DOORS et aussit6t on 

15 procede dans DOORS a la gestion et a la tragabilite de leurs exigences conformSment 
au procSde de Finvention, tel qu'exposS ci-dessus. 
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REVENDICATIONS 



1. Precede de de tragabilite des exigences k partir d'un modele UML , 
5 caracterise en ce que lors de la modelisation, on utilise une interface 

graphique lorsque Ton cree un element d'un module, on pose aussitot 
une exigence sur cet element, dans cette interface graphique et on y 
renseigne systematiquement l'exigence amont qui a provoque la 
creation de cet element 
10 2. Precede selon la revendication 1, caracterise en ce que lorsque Ton 

cree une Exigence UML) qui se repercute sur plusieurs elements du 
modele, on la rattache a Felement commun contenant F ensemble des 
elements sur lesquels l'exigence se repercute. 

3. Precede selon la revendication 1 ou 2, caracterise en ce que lorsque 
15 Ton supprime un element du modele, toutes les Exigences UML 

rattachees k cet element sont supprimees elles aussi. 

4. Precede selon la revendication 3, caracterise en ce que toutes les 
Exigences UML rattachees a tous les elements rattaches au dit 
element sont supprimees elles aussi. 

20 5. Precede selon Time des revendications precedentes, caracterise en ce 

que les Exigences UML sont exportees vers Poutil de gestion 
d'exigences « DOORS » pour y assurer leur gestion et leur 
tragabilite. 

6. Precede selon la revendication 5, caracterise en ce que les Exigences 
25 UML sont exportees vers DOORS, au cours du developpement du 

modele, a chaque fois que ce modele a atteint un etat stable. 



WO 2005/069128 



1/2 



PCT/EP2004/053362 



| Constraint : HLRJylODGJJIUU in AnActor" 
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General) Properties | 



Name: | HLR_MODGJ)100 



Stereotype: |SRS 



Defined in: | AnActor 
Body 



Description 



Title: Reset behavior 

Content: The application software shallperform 

a reset of the partition in less than 300 ms 

except in case of MACSII limitation. 

Category: Functional 

Upward Req: MB_BCSJMA_20, 

MB_BCSJMA_37,MB_SCSJMA_37. 
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